1. Field of the Invention
The present invention generally relates to the building, testing and integration of graphical user interfaces (GUI), and in one embodiment to a touch screen point-of-sale (POS) whereby the interface design, testing and maintenance is performed external to run-time code.
2. Description of the Prior Art
In recent years, touch screen devices have become commonplace in a variety of environments. For example, touch screen devices have been used in point-of-sale (POS) applications, such as in a retail establishment Within certain types of retail establishments, such as "fast food" restaurants, touch screen POS devices have become quite advantageous, given their ease of use and flexibility.
Superior interfaces are required in many cases to ensure that different types of users of touch screen interfaces can easily use these systems. Accordingly, many of these interfaces are now designed by human interface (HI) engineers, who have training in the design of human-machine interfaces, but who may or may not have an in-depth knowledge of computer programming. Moreover, it may be most efficient for a human interface engineer to not waste time performing software programming work, but rather to concentrate on his or her area of expertise. The problem then arises as to how an interface designed by an HI engineer is best communicated to customers (for approval of the design) and to software engineers (for implementation and testing of the design).
One current approach is to have HI engineers use a presentation tool like Microsoft.RTM. PowerPoint.RTM. to design and layout the graphical user interface. The problem, of course, is that this work does not contribute directly to the final interface. In other words, after an HI engineer has designed the interface, a programmer must then take the design and then start programming. Furthermore, as with any design, there will be design iterations that further compound the problem.
A better approach would be to have an HI engineer use a builder tool that utilizes graphical windows, menus, dialogs, and a common set of control names to build the user interface. A non-programmer could build the interface accurately and quickly. Then, this actual external interface would be read by a skeleton, runtime system that has just a few dummy entry level logic functions defined. The result would be that an HI engineer could very quickly get feedback on how the interface will actually look-and-feel. Also, the HI engineer would have the capability to correct errors and make improvements as the interface is fine-tuned.
Further, by providing a general-purpose tester program, the HI engineer would have another way to judge the design by watching the system run as if a human were pressing the various buttons. Should they have inadvertently forgotten to build a particular screen, then the tester would inform them of the mistake, and the HI engineer could again use the builder tool to correct the problem. Software programming personnel could also use the tester to ensure that the proper entry level logic functions are specified. Finally, when touch screen systems are deployed, it may be desirable to modify the user interface without changing the run-time interface. For example, a user might want to change a button's position, an object's color, some object text, etc.
Therefore, there is a need in the art for a system and method for building, testing, and integrating a touch screen interface into a runtime system that is simpler and less expensive than the systems and methods of the prior art, is more accurate in progressing from design to implementation, and enables non-programming personnel to do a significant amount of the design and maintenance work